Content-Type: multipart/signed; protocol="application/pkcs7-signature"; micalg=sha256; boundary="B_3746430160_3260228568" --B_3746430160_3260228568 Content-type: multipart/alternative; boundary="B_3746430160_1276696149" --B_3746430160_1276696149 Content-type: text/plain; charset="UTF-8" Content-transfer-encoding: quoted-printable Scott, =20 Thank you! My point basically was that with any accepted standard hash-func= tions (currently, SHA2 and SHA3 families) for =E2=80=9Cpre-hash=E2=80=9D, w= e=E2=80=99d be OK.=20 =20 I have no problem with SHA2-512, but even if somebody pre-hashed with SHA2-= 256, it wouldn=E2=80=99t be a problem. =20 And an IETF-specified protocol can easily require that hash-function it use= s is either collision-resistant or belongs to the =E2=80=9Capproved=E2=80= =9D set (like, what you described). =20 TNX -- V/R, Uri =20 There are two ways to design a system. One is to make it so simple there ar= e obviously no deficiencies. The other is to make it so complex there are no obvious deficiencies. = - C. A. R. Hoare =20 =20 From: "'Scott Fluhrer (sfluhrer)' via pqc-forum" Reply-To: "Scott Fluhrer (sfluhrer)" Date: Monday, September 19, 2022 at 10:36 To: Uri Blumenthal , "Scott Fluhrer (sfluhrer)" , Mike Ounsworth = , pqc-forum Cc: "pqc@ietf.org" , CFRG Subject: [pqc-forum] RE: [CFRG] Design rationale for keyed message digests = in SPHINCS+, Dilithium, FALCON? =20 =20 =20 From: CFRG On Behalf Of Blumenthal, Uri - 0553 - MI= TLL Sent: Monday, September 19, 2022 8:55 AM To: Scott Fluhrer (sfluhrer) ; Mike = Ounsworth ; pqc-forum Cc: pqc@ietf.org; cfrg@irtf.org Subject: Re: [CFRG] Design rationale for keyed message digests in SPHINCS+,= Dilithium, FALCON? =20 On the other hand, if one were to use prehashing, I would argue that the pr= ehash should be with a very conservative hash function (say, SHA-512 or SHA= 3-512); we are putting all our hybrid eggs in this one hashing basket, and = so we should make sure this one basket is a good one. =20 Do any of the currently standardized hash functions, such as SHA{2,3}-384 o= r SHA{2,3}-512 (or even SHA{2,3}-256) fail the =E2=80=9Cvery conservative= =E2=80=9D criteria? Is there any reason to expect a =E2=80=9Cweak=E2=80=9D = hash function, any more than you=E2=80=99d expect a =E2=80=9Cweak=E2=80=9D = block cipher? =20 Actually, I did suggest SHA{2,3}-512, and so they fulfill what I had in min= d by =E2=80=9Cvery conservative=E2=80=9D. =20 One could easily claim that SHA2-256 would be sufficient; however one addit= ional criteria that should be considered is cost =E2=80=93 if SHA2-512 is n= o more costly than SHA2-256, my opinion is that SHA2-512 should be preferre= d (it=E2=80=99s overkill, but there=E2=80=99s nothing wrong with cheap over= kill). I would claim that this is even more true in the hybrid scenario = =E2=80=93 the attacker can forge if either they can break the hash function= OR both of RSA and Dilithium. =20 In the scenario that=E2=80=99s immediately before us (signing with an HSM = =E2=80=93 that=E2=80=99s not the only relevant scenario, but would appear t= o be the most constrained), the obvious costs of prehashing are: =20 - The cost of performing the hash function on the full message by = the main CPU - The cost of transferring this hash to the HSM (where we transfer= more for larger hash functions) - The cost of having the HSM sign the message (which increases in = size with larger hash functions) =20 As for the first one, I believe SHA-512 is actually more efficient than SHA= -256 on 64 bit CPUs; on the other hand, if we consider smaller microcontrol= lers (32 bit), this is not as true, but it=E2=80=99s not as clear if smalle= r microcontrollers would be signing/verifying very large messages. On the = other hand, with SHA3, increasing the hash size does result in a less effic= ient hash function. =20 As for the second and third costs, I don=E2=80=99t believe that the additio= nal 256 bits or so we get when moving from SHA{23}-256 to SHA{23}-512 would= result in significantly higher costs (however hearing from some HSM vendor= s would be good) =20 =20 There are alternative approaches to this (e.g. randomizing the hash on the = main CPU and including that randomization factor in the signature), however= those go beyond the current hash-and-sign paradigm that=E2=80=99s in commo= n use. --=20 You received this message because you are subscribed to the Google Groups "= pqc-forum" group. To unsubscribe from this group and stop receiving emails from it, send an e= mail to pqc-forum+unsubscribe@list.nist.gov. To view this discussion on the web visit https://groups.google.com/a/list.n= ist.gov/d/msgid/pqc-forum/CH0PR11MB54442EB4384C9BBADAB94BF9C14D9%40CH0PR11M= B5444.namprd11.prod.outlook.com. --=20 You received this message because you are subscribed to the Google Groups "= pqc-forum" group. To unsubscribe from this group and stop receiving emails from it, send an e= mail to pqc-forum+unsubscribe@list.nist.gov. To view this discussion on the web visit https://groups.google.com/a/list.n= ist.gov/d/msgid/pqc-forum/F5173025-A84A-4438-8F44-49F222719D53%40ll.mit.edu= . --B_3746430160_1276696149 Content-type: text/html; charset="UTF-8" Content-transfer-encoding: quoted-printable

Scott,

 <= /o:p>

Thank= you! My point basically was that with any accepted standard hash-fu= nctions (currently, SHA2 and SHA3 families) for =E2=80=9Cpre-hash=E2=80=9D,= we=E2=80=99d be OK.

 

I have no problem with SHA2-512, but even if s= omebody pre-hashed with SHA2-256, it wouldn=E2=80=99t be a problem.

&n= bsp;

= And an IETF-specified protocol can easily require that hash-function it use= s is either collision-resistant or belongs to the =E2=80=9Capproved=E2=80= =9D set (like, what you described).

 

TNX

--

V/R,

Uri

=

 

There are two ways to = design a system. One is to make it so simple there are obviously no deficie= ncies.

The other is t= o make it so complex there are no obvious deficiencies.

      &nbs= p;              = ;            &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;            = ;            &n= bsp;            = ;            -&= nbsp; C. A. R. Hoare

 

 

From: "'S= cott Fluhrer (sfluhrer)' via pqc-forum" <pqc-forum@list.nist.gov>= ;
Reply-To: "Scott Fluhrer (sfluhrer)" <sfluhrer@cis= co.com>
Date: Monday, September 19, 2022 at 10:36
To: Uri Blumenthal <uri@ll.mit.edu>, "Scott Fluhrer (sfluhrer)&quo= t; <sfluhrer=3D40cisco.com@dmarc.ietf.org>, Mike Ounsworth <Mike.O= unsworth@entrust.com>, pqc-forum <pqc-forum@list.nist.gov>
C= c: "pqc@ietf.org" <pqc@ietf.org>, CFRG <cfrg@irtf.or= g>
Subject: [pqc-forum] RE: [CFRG] Design rationale for keyed = message digests in SPHINCS+, Dilithium, FALCON?

=

 

<= /div>

 

<= p class=3DMsoNormal style=3D'margin-left:.5in'> 

=

From: = CFRG <cfrg-bounces@irtf.org> On Behalf Of Blumenthal, Uri - 05= 53 - MITLL
Sent: Monday, September 19, 2022 8:55 AM
To:= Scott Fluhrer (sfluhrer) <sfluhrer=3D40cisco.com@dmarc.ietf.org>; Mi= ke Ounsworth <Mike.Ounsworth@entrust.com>; pqc-forum <pqc-forum@li= st.nist.gov>
Cc: pqc@ietf.org; cfrg@irtf.org
Subject: Re: [CFRG] Design rationale for keyed message digests in SPHINCS+, Dilith= ium, FALCON?

 

On the other hand, if one were to use prehashing, I would argue that= the prehash should be with a very conservative hash function (say, SHA-512= or SHA3-512); we are putting all our hybrid eggs in this one hashing baske= t, and so we should make sure this one basket is a good one.

=

 

Do any of the current= ly standardized hash functions, such as SHA{2,3}-384 or SHA{2,3}-512 (or ev= en SHA{2,3}-256) fail the =E2=80=9Cvery conservative=E2=80=9D criteria? Is = there any reason to expect a =E2=80=9Cweak=E2=80=9D hash function, any more= than you=E2=80=99d expect a =E2=80=9Cweak=E2=80=9D block cipher?

 

Actually, I did suggest SHA{2,3}-512, and so they fulfil= l what I had in mind by =E2=80=9Cvery conservative=E2=80=9D.

=

 

One could easily claim that SHA2-= 256 would be sufficient; however one additional criteria that should be con= sidered is cost =E2=80=93 if SHA2-512 is no more costly than SHA2-256, my o= pinion is that SHA2-512 should be preferred (it=E2=80=99s overkill, but the= re=E2=80=99s nothing wrong with cheap overkill).  I would claim that t= his is even more true in the hybrid scenario =E2=80=93 the attacker can for= ge if either they can break the hash function OR both of RSA and Dilithium.=

 <= /o:p>

In the scenario th= at=E2=80=99s immediately before us (signing with an HSM =E2=80=93 that=E2= =80=99s not the only relevant scenario, but would appear to be the most con= strained), the obvious costs of prehashing are:

 

-       &nbs= p;  The cost of perform= ing the hash function on the full message by the main CPU

-=      =      The= cost of transferring this hash to the HSM (where we transfer more for larg= er hash functions)

-          = The cost of having the HSM sign the messag= e (which increases in size with larger hash functions)

 

As for the first one, I believe SHA-512= is actually more efficient than SHA-256 on 64 bit CPUs; on the other hand,= if we consider smaller microcontrollers (32 bit), this is not as true, but= it=E2=80=99s not as clear if smaller microcontrollers would be signing/ver= ifying very large messages.  On the other hand, with SHA3, increasing = the hash size does result in a less efficient hash function.

=

 

As for the second and third costs= , I don=E2=80=99t believe that the additional 256 bits or so we get when mo= ving from SHA{23}-256 to SHA{23}-512 would result in significantly higher c= osts (however hearing from some HSM vendors would be good)

 

 

There are alternative approaches to this = (e.g. randomizing the hash on the main CPU and including that randomization= factor in the signature), however those go beyond the current hash-and-sig= n paradigm that=E2=80=99s in common use.

--
You received this message because = you are subscribed to the Google Groups "pqc-forum" group.
To = unsubscribe from this group and stop receiving emails from it, send an emai= l to pqc-forum+unsub= scribe@list.nist.gov.
To view this discussion on the web visit https://groups.google.com/a/list.n= ist.gov/d/msgid/pqc-forum/CH0PR11MB54442EB4384C9BBADAB94BF9C14D9%40CH0PR11M= B5444.namprd11.prod.outlook.com.

--
You received this message because you are subscribed to the Google Groups &= quot;pqc-forum" group.
To unsubscribe from this group and stop receiving emails from it, send an e= mail to pqc-forum+un= subscribe@list.nist.gov.
To view this discussion on the web visit https://groups.google.c= om/a/list.nist.gov/d/msgid/pqc-forum/F5173025-A84A-4438-8F44-49F222719D53%4= 0ll.mit.edu.
--B_3746430160_1276696149-- --B_3746430160_3260228568 Content-Type: application/pkcs7-signature; name="smime.p7s" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="smime.p7s" MIIUfQYJKoZIhvcNAQcCoIIUbjCCFGoCAQExDzANBglghkgBZQMEAgEFADALBgkqhkiG9w0B BwGgghJDMIIE8zCCA9ugAwIBAgITWQAE/KGDHCQY5NLn7AAAAAT8oTANBgkqhkiG9w0BAQsF ADBRMQswCQYDVQQGEwJVUzEfMB0GA1UECgwWTUlUIExpbmNvbG4gTGFib3JhdG9yeTEMMAoG A1UECwwDUEtJMRMwEQYDVQQDDApNSVRMTCBDQS01MB4XDTIwMTIxMTAwMDQ0OVoXDTI1MTIx MDAwMDQ0OVowYTELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRv cnkxDzANBgNVBAsTBlBlb3BsZTEgMB4GA1UEAxMXQmx1bWVudGhhbC5VcmkuNTAwMTA1ODQw ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCKE/w5SMRbjqdnzi3xm35MTfqSl/hP NjMbDakZIdbjOM3UKEmPFXc6a6VU/QqOJUi6ndjw0tH7RCVP73bdRPXO/E8WiAaaSYG6Ddqr 02Pv6wThtFuh+ll9IbDRWZCrXdglHg5CdvqpmlsX5UY54/Gb5r+Je3CwHewClS9/KqklAu/M Rj7Cc7g+PM9GcvU63WDVgXiuAplgvA+W5Hvmcnseb97nBuBnZ1kgbFScRNLR8y5QxSrSpXxW YRiH8dlr/LfBSYsgClZ57NhMk6Z4YL3y1Pw6Vq8pXtM7hlSq8/6s/jhxwf6vUDDeBAkoEWxl hqJtjdD+qrucwiRcrt9SNOufAgMBAAGjggGyMIIBrjAdBgNVHQ4EFgQURapIqD1qtfvgIhzU 5deTdhe9DyMwDgYDVR0PAQH/BAQDAgbAMB8GA1UdIwQYMBaAFC/vu8YNHbvpav6sZ/MHOwh2 9ktZMDMGA1UdHwQsMCowKKAmoCSGImh0dHA6Ly9jcmwubGwubWl0LmVkdS9nZXRjcmwvbGxj YTUwZgYIKwYBBQUHAQEEWjBYMC0GCCsGAQUFBzAChiFodHRwOi8vY3JsLmxsLm1pdC5lZHUv Z2V0dG8vbGxjYTUwJwYIKwYBBQUHMAGGG2h0dHA6Ly9vY3NwLmxsLm1pdC5lZHUvb2NzcDA9 BgkrBgEEAYI3FQcEMDAuBiYrBgEEAYI3FQiDg+Udh+ynZoathxWD6vBFhbahHx2Fy94yh/+K cwIBZAIBCjAiBgNVHSUBAf8EGDAWBggrBgEFBQcDBAYKKwYBBAGCNwoDDDAZBgNVHREEEjAQ gQ51cmlAbGwubWl0LmVkdTAYBgNVHSAEETAPMA0GCyqGSIb3EgIBAwEIMCcGCSsGAQQBgjcU AgQaHhgATABMAFUAcwBlAHIAUwBpAGcALQBTAFcwDQYJKoZIhvcNAQELBQADggEBABAw2S9N p+Aii+rVwD0uTZSRjpL7QD9sWkH1WB1Yd/88m+R6xZtKiD1PJLKXzcumU1V9FAPYZufhCcPV KRgyGbizPBn+f3t13bDieGHLd0DWM4abQiEgiFDsUDzTJ78WwHt/PFMjFe/oFSgghgKcOiBO QdxA7oWgV0cvJmc0hNxV6aPACboXW4qAXKMaMXPrhAXJTkL81uoemEf54gdROFIdVLYOUdba mGmstwRcTn1RsJhIcu2EDSNpyfwfK1NUNQAe199BaNenGrKW9yTHwEY55c9xusIEEaW+FLAi jseXn2gIvlQ0W2P2NMm7YCir0F6PI3DDH8+XmfcrbSfNt9swggTAMIIDqKADAgECAgEGMA0G CSqGSIb3DQEBCwUAMFYxCzAJBgNVBAYTAlVTMR8wHQYDVQQKExZNSVQgTGluY29sbiBMYWJv cmF0b3J5MQwwCgYDVQQLEwNQS0kxGDAWBgNVBAMTD01JVExMIFJvb3QgQ0EtMjAeFw0xNzAz MDIxMjAwMDBaFw0yNjAzMDIyMzU5NTlaMFExCzAJBgNVBAYTAlVTMR8wHQYDVQQKDBZNSVQg TGluY29sbiBMYWJvcmF0b3J5MQwwCgYDVQQLDANQS0kxEzARBgNVBAMMCk1JVExMIENBLTUw ggEiMA0GCSqGSIb3DQEBAQUAA4IBDwAwggEKAoIBAQCnmoMOvTkfw7nq19mrWazGaa+Q83Uv 0+ATXT3q6kr+WExIMIZ87C74WCcRXpvO7uvx7HvMsYWAFHW93wQwhjytxHIOZgKNJ4VnGVDU l+KI7g0n9+Zjt3hB3HhHbcvbe9+Y4jz+XzCiLl2OaYvICKbxvbBSCLtPEeZQ6x6Tb6EK0ym0 gvYeHO3kuuY+SJHJMltbrLnIVLxjZrNVS77zXKvu6Q3hSdkRIB7kJgEXfL+p/z/2p94bEEZ2 TnQz0TkOjG+Jq7UlXlFRtvsYcDPEQD3UNkZsWcXgC1hXG8TGknUcAhlGxVhlKlFLmNd7342s eGy2s9YxNDnSE+eXTtb0I5LLAgMBAAGjggGcMIIBmDASBgNVHRMBAf8ECDAGAQH/AgEAMB0G A1UdDgQWBBQv77vGDR276Wr+rGfzBzsIdvZLWTAfBgNVHSMEGDAWgBT/ycllTFOA8akMPCGu girH7vgy+zAOBgNVHQ8BAf8EBAMCAYYwZwYIKwYBBQUHAQEEWzBZMC4GCCsGAQUFBzAChiJo dHRwOi8vY3JsLmxsLm1pdC5lZHUvZ2V0dG8vTExSQ0EyMCcGCCsGAQUFBzABhhtodHRwOi8v b2NzcC5sbC5taXQuZWR1L29jc3AwNAYDVR0fBC0wKzApoCegJYYjaHR0cDovL2NybC5sbC5t aXQuZWR1L2dldGNybC9MTFJDQTIwgZIGA1UdIASBijCBhzANBgsqhkiG9xICAQMBBjANBgsq hkiG9xICAQMBCDANBgsqhkiG9xICAQMBBzANBgsqhkiG9xICAQMBCTANBgsqhkiG9xICAQMB CjANBgsqhkiG9xICAQMBCzANBgsqhkiG9xICAQMBDjANBgsqhkiG9xICAQMBDzANBgsqhkiG 9xICAQMBEDANBgkqhkiG9w0BAQsFAAOCAQEAMJYRwLPJ91K7e2mA2Nj10W0o5JMHYkaa+ctL 8/xY8QzIHFI5Ij+iydpPN9KCYn/4Sy80T3aNoYkFlS0GRQXhf0nsiY7TWJwAKw4AiO/yJ37/ oRKRgtyRicvaJ6RjlHCXBOalFLw9UtpodP4/idC51lxzsolaQZraBjVe7PL95PhS7D+22Nff InzLdIb1DBf54NwOVfPIgABtxH1fhZrja7EhR9RoUw5E1O6iWaAuP/xWhSTQFWlhyA0/kkIi 9/HXaY0hYnhcjcbPPqjpyfIhSFjjXhjqK7t2wPrSrBFLFUbnLiNlgQHrvNYF5IqgIfnSBWIr m3rfLhpZZJ/xJ7Yf6DCCA4owggJyoAMCAQICAQEwDQYJKoZIhvcNAQELBQAwVjELMAkGA1UE BhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsTA1BLSTEY MBYGA1UEAxMPTUlUTEwgUm9vdCBDQS0yMB4XDTE2MDQyMDEyMDAwMFoXDTM1MDQxOTIzNTk1 OVowVjELMAkGA1UEBhMCVVMxHzAdBgNVBAoTFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDDAK BgNVBAsTA1BLSTEYMBYGA1UEAxMPTUlUTEwgUm9vdCBDQS0yMIIBIjANBgkqhkiG9w0BAQEF AAOCAQ8AMIIBCgKCAQEAv3WoBEGOOJtm4ucvaf6vKIFPs8watCd6Smwq/XeRNo7P3jPIxNPw F398RGDUmPJIXA7idzD6j0opFIW+kLqYye9e788PV0dqaJlX8818fNDbSE+8B6hieqKTR7Vf OI74UVQEUKVRFuRFw6uVYuvgew2Tj/C2dEee37eruQl5nHkbV2OsWnZ7O+yt+etd6HRcaXLl P9q8WKgA3B7vkOVIMCKoAuaWj+BFq7K+WNkiyi/KdOH9JmOpbyRK4jcA7xbLnF8JFUSNg5c4 Y1BJrFaZtkCeG6Nm9p524GllkRFzPgpj8VicV+AK+9rY07dTx02kYotTnKuy0YxBAwsUXxAQ EwIDAQABo2MwYTAPBgNVHRMBAf8EBTADAQH/MB0GA1UdDgQWBBT/ycllTFOA8akMPCGugirH 7vgy+zAfBgNVHSMEGDAWgBT/ycllTFOA8akMPCGugirH7vgy+zAOBgNVHQ8BAf8EBAMCAYYw DQYJKoZIhvcNAQELBQADggEBAHqYfEf/3J5aMKhlYQ0PnUAbMB8jZSr9/HvjfOF00crFUCfS rqG8JQwo+S/iq66gcp62FEgJ0fQkDgVg6m+C2ETo1LoWiSxhYCfcSIQECljlXwR8wFSayF82 2S69IqvHhdq4d58jU6gYi6ssjU4vwsvsVLRJKk/m/Cg/w8gW6YHM5ahBD6/5Ccel2fI7oSms kO991+otrC11YfDwCFvz7Am0r+K9iVhSWta4hmIuV0YBia07eZKSO02LPgQ8YOz3ku0Yt+mh 8VWRKux2CcYjMpk+WDV0BMp75tqb6pqBFkcKvEBXqxg+8+G/umjii4H0c5kvJhaQyykbmOKm xO9IcJIwggT2MIID3qADAgECAhNZAAUW1xDL1n3IkFBHAAAABRbXMA0GCSqGSIb3DQEBCwUA MFExCzAJBgNVBAYTAlVTMR8wHQYDVQQKDBZNSVQgTGluY29sbiBMYWJvcmF0b3J5MQwwCgYD VQQLDANQS0kxEzARBgNVBAMMCk1JVExMIENBLTUwHhcNMjEwNzA2MjM0ODI1WhcNMjYwMzAy MjM1OTU5WjBhMQswCQYDVQQGEwJVUzEfMB0GA1UEChMWTUlUIExpbmNvbG4gTGFib3JhdG9y eTEPMA0GA1UECxMGUGVvcGxlMSAwHgYDVQQDExdCbHVtZW50aGFsLlVyaS41MDAxMDU4NDCC ASIwDQYJKoZIhvcNAQEBBQADggEPADCCAQoCggEBALMRXUPN5Fz28jb9GOca2/6HDq5EE4Hu T1enB0TiMEnOTipW88pgPmSZ/AAFyJF7AWX7PYPw94Ed/Bbs7yCCa6WZS7cQzdHOWppx9gRZ AxkR8+TgosxPcHoCMXmI/hXtVdZ7mwZlpBGJvyBe6YRmxOWLl3WiCRi/gBThwEWsiQZOfhEN 7hC2GhgCKetpNlTRPxslLmkStNlnjNAxhet8Vm/KSYJFVPOx3qytdLwnO6sz4AfIJJQkFX26 6oP0F/4bjRGlIZrZpdUPGiydpJl1r5SRcYs1ZE7JHErULWSyiAIzBDHUCTcN2GnFoR+9fz92 q2VIHvNHx7bV1hd0E0zlC9UCAwEAAaOCAbUwggGxMB0GA1UdDgQWBBSQ5IixU+wo9uUYNUB4 G/ea7vuWEjAOBgNVHQ8BAf8EBAMCBSAwHwYDVR0jBBgwFoAUL++7xg0du+lq/qxn8wc7CHb2 S1kwMwYDVR0fBCwwKjAooCagJIYiaHR0cDovL2NybC5sbC5taXQuZWR1L2dldGNybC9sbGNh NTBmBggrBgEFBQcBAQRaMFgwLQYIKwYBBQUHMAKGIWh0dHA6Ly9jcmwubGwubWl0LmVkdS9n ZXR0by9sbGNhNTAnBggrBgEFBQcwAYYbaHR0cDovL29jc3AubGwubWl0LmVkdS9vY3NwMD0G CSsGAQQBgjcVBwQwMC4GJisGAQQBgjcVCIOD5R2H7Kdmhq2HFYPq8EWFtqEfHYXr0HCD6+0g AgFkAgELMCUGA1UdJQQeMBwGBFUdJQAGCCsGAQUFBwMEBgorBgEEAYI3CgMEMBkGA1UdEQQS MBCBDnVyaUBsbC5taXQuZWR1MBgGA1UdIAQRMA8wDQYLKoZIhvcSAgEDAQgwJwYJKwYBBAGC NxQCBBoeGABMAEwAVQBzAGUAcgBFAG4AYwAtAFMAVzANBgkqhkiG9w0BAQsFAAOCAQEAICZO a7qQQMDGZzRUaX+Mm/3meVo0nTEdNby178MGq6uYGUS4keIkljEoI+KiEMbT8rtCOBZwomnO HdJmLuRUEgrVAos27V4yjvoic8QKsz+qEhxslFg/2EYMAbTsyLqg34R+wG5o6K95ohUrgLud fPxAmcLOFBtIZBr/3DUIlzw4xHKiX2ruex7YOrQccgXb2qGtNB7tG6jAaXqFb+NZTJhj+3pd OiZiZanzpZvPLIH6Xe4awqDrok7q9ImwwSSQorNrJxKKtA3vLUW3DGvom3XDiOjDqpzhmqXC u6Wf7JfrSJRaudU2WyvYfPk7NQlkLR/1G6Xz+zKqO/cBt2aNATGCAf4wggH6AgEBMGgwUTEL MAkGA1UEBhMCVVMxHzAdBgNVBAoMFk1JVCBMaW5jb2xuIExhYm9yYXRvcnkxDDAKBgNVBAsM A1BLSTETMBEGA1UEAwwKTUlUTEwgQ0EtNQITWQAE/KGDHCQY5NLn7AAAAAT8oTANBglghkgB ZQMEAgEFAKBpMC8GCSqGSIb3DQEJBDEiBCAzLdGN/QQFmD2sKcZfBVKqSQOikdifkpL2J4ni /qelLDAYBgkqhkiG9w0BCQMxCwYJKoZIhvcNAQcBMBwGCSqGSIb3DQEJBTEPFw0yMjA5MTkx NTAyNDBaMA0GCSqGSIb3DQEBAQUABIIBAAB0QfnbrSPvkVhfyAQj4duZRF5PmAOUBvb0/GBb fX8tmM/C+UXKecgeukIvW+B174ozGensRGbw2vCFjo8jeHyBXqkABpjFhmTZwAPyVhB4avuh YdDJPFwDQnnSx1XfSwr98Jh08YeasY5w8VZh8GiRY1hRtg8b/yjIRX1bD6gU2adnRCux2rbA 3z4NJSk8+iHlgMU0VODNlRjQZRQSnrN1IEx9BoiY57D0g4H0M0xhsNGOHCUfnOwf6JXs32Wu 7FZMIMv2mbnFDvUv5Lcu7EfY3La3k1CjR20OCRf5HYVwKHjsxmyUHzmHLfb4/TSVFz69m7nX lYP7Ov8ajA44Yc0= --B_3746430160_3260228568--